PC Direct 1995 May

home *** CD-ROM | disk | FTP | other *** search

/ PC Direct 1995 May / PC Direct CD-ROM (May 1995).ISO / ipe / misc / dosup9.exe / DEADLOCK.TXT next >

Wrap

Text File | 1993-12-21 | 17.6 KB | 460 lines

NOVELL TECHNICAL INFORMATION DOCUMENT TITLE: Deadlocks with Novell NetWare and Windows NOVELL PRODUCT and VERSION: NetWare Client for DOS/Windows ABSTRACT: These files fix a problem when using Windows or Windows for WorkGroups on a Novell network. The symptom is a blank screen with a blinking underline curser in the upper-left-hand corner of the screen and the workstation hangs. _________________________________________________________________ DISCLAIMER THE ORIGIN OF THIS INFORMATION MAY BE INTERNAL OR EXTERNAL TO NOVELL. NOVELL MAKES EVERY EFFORT WITHIN ITS MEANS TO VERIFY THIS INFORMATION. HOWEVER, THE INFORMATION PROVIDED IN THIS DOCUMENT IS FOR YOUR INFORMATION ONLY. NOVELL MAKES NO EXPLICIT OR IMPLIED CLAIMS TO THE VALIDITY OF THIS INFORMATION. _________________________________________________________________ ADDITIONAL CONFIGURATION Third-Party Product and Version: Windows Windows for WorkGroups SYMPTOM The symptom is a blank screen with a blinking underline curser in the upper-left-hand corner of the screen and the workstation hangs. This may happen at any time while in Windows, launching a dos box, using a Windows application or exiting Windows. The following is a list of causes/solutions that Novell has isolated that can cause/remedy the symptom described above. CAUSE IPXODI.COM had a bug in SPX. During a retry, SPX would jump to invalid memory causing an invalid opcode exception in v86 mode only when SPX is being used. Few applications use SPX. This usually manifests itself as a reboot, hung machine, or blank screen with cursor in upper-left corner. CAUSE LSL.COM had a bug that was GetStackECBPrescanIsPresent destroyed the return Flag when an ECB was given. The symptom of this problem would most likely manifest it self by a workstation hang when using a protocol stack that expects to get an ECB from the LSL under a heavy load. CAUSE LSL.COM also had a problem with the "Do Send for Windows" code that needed a "Start and End Critical Section" call added. CAUSE An incorrect system configuration including memory management. CAUSE Any I/O, memory, or IRQ conflicts may cause this problem. CAUSE Using third-party device drivers or terminate-and-stay-resident (TSR) programs. CAUSE Lan Card MLID driver's misuse of ECB buffers. CAUSE Third party protocol stacks, such as TCPIP. CAUSE VIPX.386 is a Windows 3.X virtualization driver for IPXODI.COM driver that was enhanced jointly by Novell and Microsoft. It virtualizes requests to the globally loaded IPX driver. When a request is made to IPX, VIPX will allocate a request buffer in the system's global memory, copy the original request to the global buffer and give the global request to IPX. When the global request completes, IPX will call VIPX. VIPX will then copy any results back to the original request buffer and call the application that submitted the request. CAUSE Some Windows applications have been found to create the symptom if when exiting Windows the application is running in the background in a minimized state. If this occurs, close all applications before leaving Windows. CAUSE There are occasions when using a Winstart.bat file (which is created by the user and placed in the Windows directory) may also cause Windows to hang when exiting Windows. Avoid a Winstart.bat file if the symptom persists. CAUSE Microsoft has a patch called VTDA.386 for their Windows 3.1 VTD driver. VTDA.386 obtainable from Microsoft. Their BBS number is 206-936-6735 and the file to down load is WW0863.EXE. Version Compatibility with Dedicated IPX ---------------------------------------- Novell officially ceased maintenance on the dedicated IPX driver (IPX.OBJ) version 3.10 dated 11-21-91. The last version of VIPX to explicitly support that driver is 1.10. The current version of VIPX supports IPXODI.COM only. Packet Size Limitations ----------------------- VIPX.386 will only virtualize packets that are 8000 (decimal) bytes or less. Any DOS and Windows IPX or SPX applications that use networks with a physical packet size greater than 8000 bytes may not work with VIPX.386. For example, IBM Token Ring can be configured to run with 16 KB packets. A request by a DOS or Windows IPX application to send a 16 KB packet will be truncated to 8000 bytes. On the other hand, any 16 KB packet that is received by the LAN driver will be dropped because VIPX cannot allocate a packet big enough to handle it. Memory Manager Limitations -------------------------- When a request is passed up from IPX, VIPX will immediately test the request buffer to see if it is in global memory. If it is in global memory, the request will be passed back down to IPX without any virtualization. For example, a TSR loaded before Windows is considered to be in global memory. If that TSR calls IPX, VIPX will test the requests and pass them back down to IPX. This is done because there is no need to virtualize requests that are already global. The use of UMA memory complicates the test for global memory. There are two basic scenarios. The first scenario is when a TSR has been loaded high before Windows was loaded. In this case, IPX requests will come from global UMA memory. VIPX will simply pass these requests back down to IPX. The second scenario is when a TSR is loaded high in a Windows DOSBOX. In this case, IPX requests will come from local UMA memory. VIPX will virtualize these requests. Some memory managers test for global UMA memory and will work properly under both scenarios. However, other memory managers exist that do not work properly under Windows. With these drivers, all local DOSBOX UMAs look as if they are GLOBAL UMAs. In the case of the second scenario when a TSR calls IPX, VIPX will test the request buffer and think that it is in global UMA memory when it is really in LOCAL UMA memory. As a result, VIPX will pass a local ECB to IPX without virtualization. The normal result of this is a hung machine or data corruption. SOLUTION Novell strongly recommends that you update your dedicated IPX driver with IPXODI.COM v2.12, included in DOSUP9.EXE, when using versions of VIPX later than 1.10. Because of the problems with LSL.COM, Novell also recommends that you update your LSL.COM to v2.05. This version is also available in DOSUP9.EXE in the NOVFILES forum of Compuserve. If you are using third-party memory managers and hang, do not load TSRs using the IPX interface (including IPX itself) high. Load then in conventional memory only. Files Needed: Size Date Version Location VIPX.386 23855 10-08-93 1.17 WINUP9.EXE IPXODI.COM 30247 10-07-93 2.12 DOSUP9.EXE LSL.COM 17805 09-10-93 2.05 DOSUP9.EXE Installation Instructions: 1. Rename or backup the old VIPX.386, IPXODI.COM, and LSL.COM files. 2. Copy IPXODI.COM and LSL.COM to where the network board's software is initialized. 3. Copy VIPX.386 to your WINDOWS\SYSTEM directory. 4. Virtualize the network board's IRQ in the [VIPX] section of the SYSTEM.INI if using IBM LAN SUPPORT. 5. Put TimerCriticalSection=10000 in the [386Enh] section of the SYSTEM.INI. 6. Download, and implement the VTDA.386 driver from MicroSoft. 7. Reboot the machine and load the ODI drivers. 8. Enter Windows. Solution Specifics: Specialized Configuration Parameters ------------------------------------ Under most circumstances, VIPX will work fine under the default configuration. However, there may be some applications that require custom configuration of the driver. This following is a list of SYSTEM.INI parameters that can be used to configure VIPX: [VIPX] VipxMappingPages =[number of 4K pages] (default = 16) VipxFailOverSizedPackets =[ON|OFF|TRUE|FALSE] (default = OFF) VirtualizeIrq[0-F] =[ON|OFF|TRUE|FALSE] (default = OFF) VIPX Parameters VipxMappingPages ---------------- This is the number of pages that VIPX can use to globalize requests to the global IPXODI.COM driver. VIPX is not absolutely guaranteed to have all of these pages available at any one point, because this is the requested number of pages for shared global mapping that VIPX makes to the Windows VMM at initialization time. VipxFailOverSizedPackets ------------------------ This parameter tells VIPX to fail any requests that require more than the maximum allowed globalization size. The actual maximum will vary according to the media the user is using. The absolute maximum is 8000 (decimal) bytes. With media that have smaller packets than 8000 bytes, the maximum allowed size is the maximum packet size that can be put onto the media. VirtualizeIrq[0-F] ------------------ VIPX v1.15 or greater avoids a deadlock between the machine and network board by virtualizing the network board's IRQ. With ODI and dedicated IPX (IPX.OBJ) drivers, VIPX will automatically read the configuration of the network board from the driver and virtualize the selected IRQs. However, when using the IBM LAN Support Program with SLANSUP.OBJ or LANSUP.COM, the LAN IRQ is not readable from the driver. The only way to get this information is to read the network board hardware itself. The problem with doing this is that the hardware can be Token Ring, PCN2 or Ethernet. VIPX must now be aware of many different hardware configurations. Instead of this, VIPX requires the IBM LAN Support user to specify the network board's IRQ in the [VIPX] section of the SYSTEM.INI. IRQs range from 0 to F (hex). An example is listed below: [VIPX] VirtualizeIrq2=TRUE VirtualizeIrq3=TRUE In this example, VIPX will virtualize both IRQ 2 and IRQ 3. VIPX can virtualize up to four different LAN IRQs. The reason for virtualizing multiple IRQs is to allow other LAN boards and protocols to be installed on the same PC and prevent them from deadlocking the machine. For example, you may have IPX running through an NE2000 board on IRQ 3 and TCP/IP running through to an IBM Token-Ring board on IRQ 2. TimerCriticalSection -------------------- As of version 1.15 of VIPX, TimerCriticalSection is required to be set on. The recommended setting is as follows: [386Enh] TimerCriticalSection=10000 The reason for this parameter is to avoid a deadlock with the LAN IRQ Virtualization code. See "VirtualizeIrq[0-F]" section. Changes to LSL.COM v2.05 1. GetStackECBPrescanIsPresent destroyed the return Flag when an ECB was given. The symptom of this problem would most likely manifest it self by a workstation hang when using a protocol stack that expects to get an ECB from the LSL under a heavy load. 2. Added a line to correct ECBLISTHEAD overwriting of variable StackECBHoldQHead. Changes to LSL.COM v2.02 1. Commandline Switches: Valid switches: U, F, ?, H, C= Only the "U, ?, C=" are documented in the help. U Used to unload LSL. ? Used for Help. F Used to force the unload. H Used as an equivalent to "?" switch, and is used by many of Novell's other utilities. C= Used to change the path or filename of the configuration file. The "C=" switch is the only two-letter switch that is valid, Custom Configuration Files. When using the "C=" command-line switch, the LSL first tries the [path]\filename as given. If the file is not found, then the filename is searched for in the directory where the LSL was loaded from; and if it still cannot be found, it looks in the current working directory. If all these efforts fail, then the LSL reverts back to looking for a "NET.CFG" file in the directory where the LSL was loaded from then in the current working directory. The filename is considered valid even if the path was incorrect. After parsing the Configuration file, the LSL displays the relative path of the Configuration file that was parsed. 2. LSL.COM had a number of bugs and one was a bug that caused a deadlock situation with the LAN adapter. A Do Send for Windows needed a Start and End Critical Section call added. It is now language enabled. 3. Multiple Prescan Stack Chaining did not pass a packet properly. 4. GetProtocolControlEntry would not return the DefaultProtocol Control Entry point if it was not the only stack in the DefaultProtocolChain. 5. Bound checking was added on the MLID Support Functions. 6. Error code not preserved in Deregister Prescan Tx chain. 7. A bug in Memory Calculation when calculating the amount of memory to reserve when going TSR was fixed. 8. The LSL, while checking for boards and Protocols that were still registered would unload from memory, leaving the still registered entities with bad pointers. The LSL will now remove all the MLIDS, through the SHUTDOWN command. The LSL will not unload if a Protocol stack is still registered with the LSL. 9. On Installation of a LAN driver, the LSL would check the version of the Configuration Table and delete the board number. This is now fixed. 10. On unload of a LAN driver, the driver called MLIDSUP_DEREGISTER_MLID, which called MLIDSUP_CONTROL_STACK_FILTER. When testing for board numbers that are bound to the MLID, a JNE was used where a JE was needed. IPXODI.COM Command line Switches: Valid switches: /?, /D, /A, /C=, /U, /F ? Used for help screen. D Used for Eliminate Diagnostic Responder; reduces size by 3 KB. A Used for Eliminate Diagnostic Responder and SPX; reduces size by 9 KB. PLEASE NOTE: Disabling SPX will mean that SPX applications (such as RPRINTER, BTRIEVE, RCONSOLE, or Netware for SAA STRNRTR) will not be supported on this workstation. C= Used to change the path or filename of the configuration file. "C=" is the only two letter switch that is valid. If the *.CFG file used does not exist a message will be displayed that the standard NET.CFG file will be used instead. U Used to unload. F Used to force the unload. IPXODI.COM v2.12 Released for NetWare 4.01 Update 1. Fixed SPX problem that was seen using NASI/NACS modem sharing data. This problem shows up when using an SPX applications that is transferring data in full duplex mode (most SPX applications do not do this). The code was advancing the session sequence number in the local session table immediately after sending an SPX data packet to the other side. If a data packet came in from the other side that did not acknowledge Novell's "send," Novell would generate a system packet back to the other end with the session sequence number set to the value in the local session table, which is one higher than what it should be. Then if Novell's data packet got dropped, Novell would retransmit it, in which case the other end would ignore our packet since it session sequence number was not high enough. This would result in session failure. 2. Enhanced initialization code to check the board's node ID for all 0FFs. If it is then we display an error and fail to load. This enhancement was requested by Novell Austin for support of his serial line ODI drivers which set the node Id to all 0FFs if the user hasn't made a connection. A new error message has been created for this condition, however the code checks to see if the msg file IPXODI is using has the new error message. If it does not, then the error condition is ignored and IPXODI still loads. This will allow current/older msg files to be used successfully. 3. A problem in RxHandler was fixed that was introduced in IPXODI v2.00 where in the case Novell steals a mapping ECB then they have to have VIPX get a client receive ECB. Novell was not preserving register AX, which was supposed to have the destination socket number. In this case, VIPX would return that there was not any receive ECB since it thought the socket was not opened when in reality it was and it had receives posted. This bug can cause back-to-back receive packets to be dropped when the packets are destined for an IPX application (DOS or Windows) running under Enhanced mode Windows. 4. Novell fixed IPX diagnostic responder code so it would return a 0FFFFh in the SPX socket number field of the IPX diagnostic query reply packet when SPX or diagnostic portion of IPXODI has not be loaded by the user. This provides a method for diagnostic applications to determine if SPX is there or not so they do not have to attempt a SPX connect request if SPX is not there. IPXODI.COM 04-23-93 v2.11 Released for NMS and NetWare 4.01 Release 1. Implemented fix in SPX.ASM SPXConnectHandler routine where it was not preserving the session count in CX when comparing the session addresses. This problem exists in the dedicated IPX/SPX module as well. To see this problem the same source connection ID would have to be in use by two nodes trying to connect to a particular node. 2. Novell fixed a bug in SPXMessageHandler routine where it was setting the a send ECB's ESR to SessionSendCompletedDelayed without a group "CGroup:" override that caused a bogus offset to be put in the ESR offset field. Thus when the active send finished it would blow up. This problem exists in the dedicated IPX/SPX module as well. This problem showed itself while running the Novell NMS Windows application for a few hours. 3. IPXODI.COM had a bug in SPX. During a retry, SPX would jump to invalid memory causing an invalid opcode exception in v86 mode only when SPX is being used. Few applications use SPX. This usually manifests itself as a reboot, hung machine, or blank screen with cursor in upper-left corner.